In a future “Networked Society” scenario there are expected to be a very large number of machine-type-communication (MTC) devices supported by wide-area wireless networks. Many of these devices will transmit a small amount of uplink data (e.g., 100 bits) very infrequently (e.g., once per hour). The 3rd-Generation Partnership Project (3GPP), in its continuing standardization of technology for Long-Term Evolution (LTE), plans to introduce a new solution for “enhanced MTC coverage,” with a goal of improving the link budget under enhanced MTC coverage by approximately 15-20 dB, compared to what is supported with the legacy LTE standard. (See, for example, 3GPP Tdoc RP-121441, available at http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_57//Docs/.) This is expected to make LTE even more attractive for MTC type of solutions.
Machine-to-machine (M2M) communication, also known as machine-type communication (MTC), is used for establishing communication between machines and between machines and humans. The communication may comprise of exchange of data, signaling, measurement data, configuration information, etc. The device size may vary from that of a wallet to that of a base station. M2M devices are quite often used for applications like sensing environmental conditions (e.g., temperature reading), metering or measurement (e.g., electricity usage, etc.), fault finding or error detection, etc. In these applications, the M2M devices are active very infrequently, but over a particular duration that depends upon the type of service, e.g., about 200 milliseconds once every 2 seconds, about 500 milliseconds every 60 minutes, etc. An M2M device may also perform measurements on frequencies or other RATs other than the frequency or RAT of the cell serving the M2M device.
A M2M communication device can be distinguished from a normal user equipment or “UE,” which is 3GPP terminology for a radio access terminal such as a cellular phone, in that the former can communicate with another UE, which can be a M2M device or a normal UE, without human interaction. An M2M device can be identified as such by a network node by the device's capability information, which indicates that it is M2M capable. The capability information is typically signaled by the M2M device to the network node.
The path loss between an M2M device and a base station can be very large in some scenarios, such as when the device is used as a sensor or metering device located in a remote location like the basement of a building. In such scenarios, the reception of the signal transmitted from the base station is very challenging. For example, the path loss can be 20 dB (or more) worse than what is observed by conventional devices in normal situations.
To cope with such challenges, the coverage in uplink and/or in downlink has to be substantially enhanced. This can be realized by employing one or several advanced techniques in the UE and/or in the radio network node for enhancing the coverage. Non-limiting examples of such advanced techniques include transmit power boosting, repetition of transmitted signal, applying additional redundancy to the transmitted signal, use of advanced/enhanced receiver, etc. In general, the M2M can be regarded as operating in “coverage-enhancement mode” or “enhanced-coverage mode” when employing such coverage enhancing techniques. However, in some scenarios, such as when the coverage (e.g., path loss) between M2M device and the radio network node is within normal level, then coverage enhancing techniques are not needed. In this case the M2M device is regarded as operating in “normal-coverage mode.” The terms “non-coverage-enhancement mode” and “normal mode” can be interchangeably used with “normal-coverage mode” in the present context.
Depending upon the path loss between M2M device and its serving radio network node, a M2M device and/or radio network node can be configured to operate in “coverage-enhancement mode” or in “normal mode.” For example, if the path loss is larger than a particular threshold (e.g., 100 dB), then the coverage-enhancement mode can be employed, while the normal-coverage mode is employed otherwise.
General requirements for many MTC devices, which are often referred to as “sensors,” or “sensor devices,” include that they be low-cost and consume little energy. One way to achieve reduced cost and energy consumption in these devices is to reduce the bandwidth that the devices are required to support. (Again, see, e.g., 3GPP Tdoc RP-121441.) In the LTE context in particular, it has been suggested that these sensors be designed to support the smallest possible bandwidth supported within 3GPP LTE, which is 1.4 MHz. However, a remaining challenge is how to schedule those devices supporting reduced bandwidth within an LTE system, without affecting the performance of normal 3GPP LTE users.
The concept of mixing machine-type traffic with human-centric traffic (e.g., traffic generated by conventional cellular phones, smartphones, wireless-enabled tablets and computers, etc.) has recently appeared for the first time within 3GPP. This has generated a significant number of new ideas and concepts. Within 3GPP, a number of general proposals regarding this topic have been made. As an example, contributions to the 3GPP RAN 1 working group include such contributions as 3GPP Tdoc R1-132879, “Analysis and discussion on bandwidth reduction”, Huawei, HiSilicon, available at http://www.3gpp.org/ftp/tsg_ran/wg1_rl1/TSGR1_74/Docs/, and 3GPP Tdoc R1-133018, “Downlink bandwidth reduction for low cost MTC UEs for LTE”, CATT, available at http://www.3gpp.mobi/ftp/tsg_Ran/WG1_RL1/TSGR1_74/Docs/.
In these contributions, high-level trade-offs are described for the use of spectrum bands to be used for M2M within the LTE spectrum. Proposals for either dedicated spectrum allocation, or dynamic, or semi-static allocation for M2M have been made. However, no mechanism is provided for indicating which resources of the system are going to be allocated to M2M. Moreover, no other structure, physical or logical mechanism within 3GPP specifications exists in which different type of traffic is mixed with the normal traffic to be supported by LTE.